home *** CD-ROM | disk | FTP | other *** search
/ Danny Amor's Online Library / Danny Amor's Online Library - Volume 1.iso / html / rfc / rfcxxxx / rfc1568 < prev    next >
Text File  |  1995-07-26  |  17KB  |  451 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                           A. Gwinn
  8. Request for Comments: 1568                 Southern Methodist University
  9. Category: Informational                                     January 1994
  10.  
  11.  
  12.              Simple Network Paging Protocol - Version 1(b)
  13.  
  14. Status of this Memo
  15.  
  16.    This memo provides information for the Internet community.  This memo
  17.    does not specify an Internet standard of any kind.  Distribution of
  18.    this memo is unlimited.
  19.  
  20. Abstract
  21.  
  22.    This RFC suggests a simple way for delivering both alphanumeric and
  23.    numeric pages (one-way) to radio paging terminals.  Gateways
  24.    supporting this protocol, as well as SMTP, have been in use for
  25.    several months in one nationwide paging firm.  One other paging firm
  26.    is in the process of adopting it.
  27.  
  28.    Earlier versions of this specification were reviewed by IESG members
  29.    and the IETF's "822 Extensions" Working Group.  They preferred an
  30.    alternate strategy, as discussed under "Relationship to Other IETF
  31.    Work", below.
  32.  
  33. 1. Introduction
  34.  
  35.    Beepers are as much a part of computer nerdom as X-terminals
  36.    (perhaps, unfortunately, more).  The intent of Simple Network Paging
  37.    Protocol (SNPP) is to provide a standard whereby pages can be
  38.    delivered to individual paging terminals.  The most obvious benefit
  39.    is the elimination of the need for modems to produce alphanumeric
  40.    pages, and the added ease of delivery of pages to terminals in other
  41.    cities or countries.  Additionally, automatic page delivery should be
  42.    somewhat more simplified.
  43.  
  44. 2. System Philosophy
  45.  
  46.    Radio paging is somewhat taken for granted, because of the wide
  47.    availability and wide use of paging products.  However, the actual
  48.    delivery of the page, and the process used (especially in wider area
  49.    paging) is somewhat complicated.  When a user initiates a page, by
  50.    dialing a number on a telephone, or entering an alphanumeric page
  51.    through some input device, the page must ultimately be delivered to
  52.    some paging terminal, somewhere.  In most cases, this delivery is
  53.    made using TAP (Telocator Alphanumeric input Protocol, also known as
  54.    IXO).  This protocol can be a somewhat convoluted, and complicated
  55.  
  56.  
  57.  
  58. Gwinn                                                           [Page 1]
  59.  
  60. RFC 1568                  SNPP - Version 1(b)               January 1994
  61.  
  62.  
  63.    protocol using older style ASCII control characters and a non-
  64.    standard checksumming routine to assist in validating the data.  One
  65.    note: even though the TAP protocol allows for a password for sending
  66.    simple pages, they are rarely used (especially in commercial
  67.    markets), and therefore support for them has not been implemented in
  68.    this version of the protocol.
  69.  
  70.    Even though TAP is widely used throughout the industry, there are
  71.    plans on the table to move to a more flexible "standard" protocol
  72.    (the proposal for which is actually more convoluted than most
  73.    Internet RFC's).  However, acknowledging the complexity and
  74.    flexibility of the current protocols (or the lack thereof), the final
  75.    user function is quite simple: to deliver a page from point-of-origin
  76.    to someone's beeper.  That is the simple, real-time function that
  77.    this protocol attempts to address.  Validation of the paging
  78.    information is left completely up to the TAP/IXO paging terminal,
  79.    making an SNPP gateway a direct "shim" between a paging terminal and
  80.    the Internet.
  81.  
  82. 3. Why not just use Email and SMTP?
  83.  
  84.    Email, while quite reliable, is not always timely.  A good example of
  85.    this is deferred messaging when a gateway is down. Suppose Mary Ghoti
  86.    (fish@hugecompany.org) sends a message to Zaphod Beeblebrox's beeper
  87.    (5551212@pager.pagingcompany.com). Hugecompany's gateway to the
  88.    Internet is down causing Mary's message to be deferred.  Mary,
  89.    however, is not notified of this delay because her message has not
  90.    actually failed to reach its destination.  Three hours later, the
  91.    link is restored, and (as soon as sendmail wakes up) the message is
  92.    sent.  Obviously, if Mary's page concerned a meeting that was
  93.    supposed to happen 2 hours ago, there will be some minor
  94.    administrative details to work out between Mary and Zaphod!
  95.  
  96.    On the other hand, if Mary had used her SNPP client (or simply
  97.    telnetted to the SNPP gateway), she would have immediately discovered
  98.    the network problem.  She would have decided to invoke plan "B" and
  99.    call Zaphod's pager on the telephone, ringing him that way.
  100.  
  101.    The obvious difference here is not page delivery, but the immediate
  102.    notification of a problem that affects your message.  Standard email
  103.    and SMTP, while quite reliable in most cases, cannot be positively
  104.    guaranteed between all nodes at all times, making it less desirable
  105.    for emergency or urgent paging.  The other consideration is the
  106.    relative simplicity of the SNPP protocol for manual Telnet sessions
  107.    versus someone trying to manually hack a mail message into a gateway.
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Gwinn                                                           [Page 2]
  115.  
  116. RFC 1568                  SNPP - Version 1(b)               January 1994
  117.  
  118.  
  119. 4. The Future of SNPP
  120.  
  121.    While the current form of the SNPP protocol is designed for use with
  122.    TAP/IXO, it is intended to provide a porting base for use with the
  123.    newer TME (TDP) protocol.  In addition, future releases of SNPP will
  124.    allow for multiple recipient messages with individual "envelope"
  125.    options and specifications as allowed by TME.  For example, the
  126.    protocol should allow the user to specify delivery of an urgent
  127.    message to Zaphod in Denver, while carbon-copying Mary in Des Moines
  128.    at a lower priority.
  129.  
  130. 5. The Protocol
  131.  
  132.    The SNPP protocol is a sequence of commands and replies, and is based
  133.    on the philosophy of many other Internet protocols currently in use.
  134.    SNPP has six input commands (the first 4 characters of each are
  135.    significant) that solicit various server responses falling into three
  136.    categories: (1) successful, (2) failed-but-continue, and (3) failed-
  137.    with-connection-terminated.  The first character of every server
  138.    response code is a digit indicating the category of response: '2xx',
  139.    '5xx', and '4xx' respectfully.  The text portion of the response
  140.    following the code may be altered to suit individual applications.
  141.  
  142.    The session interaction is actually quite simple (hence the name).
  143.    The client initiates the connection with the listening server.  Upon
  144.    opening the connection, the server issues a greeting followed by "250
  145.    READY" (indicating the willingness of the server to accept SNPP
  146.    commands).  The client passes pager ID information, and a message,
  147.    then issues a "SEND" command.  The server then feeds the information
  148.    to the TAP paging terminal, gathers a response, and reports the
  149.    success or failure to the client.
  150.  
  151. 6.1 A Typical Successful Connection
  152.  
  153.            Client                         Server
  154.  
  155.    Open Connection            -->
  156.                               <--  220 SNPP Gateway Ready
  157.    PAGE 5551212               -->
  158.                               <--  250 OK
  159.    MESS Your network is hosed -->
  160.                               <--  250 OK
  161.    SEND                       -->
  162.                               <--  250 Page Sent
  163.    QUIT                       -->
  164.                               <--  221 OK, Goodbye
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Gwinn                                                           [Page 3]
  171.  
  172. RFC 1568                  SNPP - Version 1(b)               January 1994
  173.  
  174.  
  175. 6.2 Commands
  176.  
  177. 6.2.1 PAGEr <Pager ID>
  178.  
  179.    The PAGEr command sets the pager ID (PID) number, for the
  180.    transaction, into the gateway.  The PID used must reside in the TAP
  181.    terminal (and there is where it should be validated).  Limited
  182.    validation may optionally be done on the server (such as all numeric,
  183.    and ID length), or it can all be done by the TAP terminal at the time
  184.    the page is sent.  Duplicating the PAGEr command before SENDing the
  185.    message should produce an "503 ERROR, Already Entered" message, and
  186.    allow the user to continue.
  187.  
  188.    In the future, a series of PAGEr commands may be specified to allow
  189.    for multiple recipients of the same message.  Right now, however,
  190.    TAP/IXO only validates the PID at the time the message is accepted by
  191.    the paging terminal.  This makes "pre" validation of PID's currently
  192.    difficult.
  193.  
  194. 6.2.2 MESSage <Alpha or Numeric Message>
  195.  
  196.    The MESSage command sets the numeric or alphanumeric message for the
  197.    transaction, into the gateway.  Limited validation of the message may
  198.    be done on the SNPP server (such as length), but type-of-message
  199.    validation should be done by the TAP/IXO paging terminal.
  200.    Duplicating the MESSage command before SENDing the message should
  201.    produce an "503 ERROR, Already Entered" message, and allow the user
  202.    to continue.
  203.  
  204. 6.2.3 RESEt
  205.  
  206.    The RESEt command clears the PAGEr and MESSage fields, and allows the
  207.    client to start over.  This is provided, primarily, as a means to
  208.    reset accidentally entered information during a manual session. Upon
  209.    a successful reset, the server should respond "250 RESET OK".
  210.  
  211. 6.2.4 SEND
  212.  
  213.    The SEND command processes the page to the TAP terminal.  Prior to
  214.    processing, the PAGEr and MESSage fields should be checked for the
  215.    existence of information.  Should one of these required fields be
  216.    missing, the server should respond "503 Error, Incomplete
  217.    Information" and allow the user to continue.  Assuming all of the
  218.    fields are filled in, the SNPP server should format and send the page
  219.    to the TAP terminal, and await a response.  Upon receiving a reply,
  220.    the server should respond as follows:
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Gwinn                                                           [Page 4]
  227.  
  228. RFC 1568                  SNPP - Version 1(b)               January 1994
  229.  
  230.  
  231.     250 Page Sent         - successful delivery
  232.     554 Failed, <reason>  - unsuccessful, and gives a reason
  233.  
  234.    Or, in the case of an illegal or non-existent pager ID, or some other
  235.    administrative reason for rejecting the page, the server should
  236.    respond:
  237.  
  238.     550 Failed, Illegal Pager ID (or other explanation)
  239.  
  240.    After processing a SEND command, the server should remain online to
  241.    allow the client to enter another page.
  242.  
  243. 6.2.5 QUIT
  244.  
  245.    The QUIT command terminates the current session.  The server should
  246.    respond "221 OK, Goodbye" and close the connection.
  247.  
  248. 6.2.6 HELP
  249.  
  250.    The HELP command (optional) displays a screen of information about
  251.    commands that are valid on the SNPP server.  This is primarily to
  252.    assist manual users of the gateway.  Each line of the HELP screen
  253.    (responses) are preceded by a code "214".  At the end of the HELP
  254.    sequence, a "250 OK" is issued.
  255.  
  256. 6.3 Illegal Commands
  257.  
  258.    Should the client issue an illegal command, the server should respond
  259.    "421 ERROR, Goodbye" and close the connection immediately.
  260.    Optionally, the server may respond "502 Command Error, try again"
  261.    should it be desirable to leave the connection open.
  262.  
  263. 6.4 Timeouts
  264.  
  265.    The SNPP server can, optionally, have an inactivity timeout
  266.    implemented.  At the expiration of the allotted time, the server
  267.    responds "421 Timeout, Goodbye" and closes the connection.
  268.  
  269. 6.5 Rigidity of Command Structure
  270.  
  271.    The commands from client to server should remain constant.  However,
  272.    since the first character of the response indicates success or
  273.    failure, the text of the server responses could be altered should one
  274.    desire.  The following is a hunk of C code that is used currently in
  275.    an SNPP gateway.  The only response that has not been discussed is
  276.    "421 SERVER DOWN, Goodbye" and is used when the gateway is
  277.    administratively down, or when there are communication problems with
  278.    the TAP/IXO paging terminal.
  279.  
  280.  
  281.  
  282. Gwinn                                                           [Page 5]
  283.  
  284. RFC 1568                  SNPP - Version 1(b)               January 1994
  285.  
  286.  
  287.    /* SNPP Client Commands */
  288.  
  289.    #define PAGER        "PAGE"
  290.    #define MESSAGE      "MESS"
  291.    #define SEND         "SEND"
  292.    #define QUIT         "QUIT"
  293.    #define RESET        "RESE"
  294.    #define HELP         "HELP"
  295.  
  296.    /* Responses from SNPP server to client */
  297.  
  298.    #define SNPP_OK      "250 OK"
  299.    #define SNPP_RESET   "250 Reset OK"
  300.    #define SNPP_SENT    "250 Page Sent"
  301.    #define SNPP_BADPIN  "550 Failed,"
  302.    #define SNPP_NOTSENT "554 Failed,"
  303.    #define SNPP_ENTERR  "503 Error, Already Entered"
  304.    #define SNPP_ERRINC  "503 Error, Incomplete Info"
  305.    #define SNPP_OKCLOS  "221 OK, Goodbye"
  306.    #define SNPP_TIMEOUT "421 Timeout, Goodbye"
  307.    #define SNPP_ERRCLOS "421 ERROR, Goodbye"
  308.    #define SNPP_DOWN    "421 SERVER DOWN, Goodbye"
  309.  
  310. 7. Revision History
  311.  
  312.    Originally, when proposed, the author employed POP2 style
  313.    result/response codes.  The Internet community suggested that this
  314.    '+' and '-' style theory be altered to provide numeric response codes
  315.    -- similar to those used in other services such as SMTP.  The
  316.    protocol has been altered to this specification from the first
  317.    proposed draft.
  318.  
  319.    When a bad pager ID message (IXO/TAP administrative failure was
  320.    received from the paging terminal, a 554 series (general failure) was
  321.    returned.  This has been changed to a 550 failure code allowing a
  322.    distinction to be made.
  323.  
  324. 8. Relationship to Other IETF Work
  325.  
  326.    The strategy of this specification, and many of its details, were
  327.    reviewed by an IETF Working Group and three IESG members.  They
  328.    concluded that an approach using the existing email infrastructure
  329.    was preferable, due in large measure to the very high costs of
  330.    deploying a new protocol and the advantages of using the Internet's
  331.    most widely-distributed applications protocol infrastructure.  Most
  332.    reviewers felt that no new protocol was needed at all because the
  333.    special "deliver immediately or fail" requirements of SNPP could be
  334.    accomplished by careful configuration of clients and servers.  The
  335.  
  336.  
  337.  
  338. Gwinn                                                           [Page 6]
  339.  
  340. RFC 1568                  SNPP - Version 1(b)               January 1994
  341.  
  342.  
  343.    experimental network printing protocol [3] was identified as an
  344.    example of an existing infrastructure approach to an existing
  345.    problem.  Other reviewers believed that a case could be made for new
  346.    protocol details to identify paging clients and servers to each other
  347.    and negotiate details of the transactions, but that it would be
  348.    sensible to handle those details as extensions to SMTP [1,2] rather
  349.    than deploying a new protocol structure.
  350.  
  351.    The author, while recognizing these positions, believes that there is
  352.    merit in a separate protocol to isolate details of TAP/IXO and its
  353.    evolving successors from users and, indeed, from mail-based
  354.    approaches that might reach systems that would act as SMTP/MIME [4]
  355.    to SNPP gateways.  Such systems and gateways are, indeed, undergoing
  356.    design and development concurrent with this work.  See the section
  357.    "Why not just use Email and SMTP?" for additional discussion of the
  358.    author's view of the classical electronic email approach.
  359.  
  360. 9. References
  361.  
  362.    [1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
  363.        USC/Information Sciences Institute, August 1982.
  364.  
  365.    [2] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker,
  366.        "SMTP Service Extensions", United Nations University, Innosoft,
  367.        Dover Beach Consulting, Inc., Network Management Associates,
  368.        Inc., The Branch Office, February 1993.
  369.  
  370.    [3] Rose, M., and C. Malamud, "An Experiment in Remote Printing", RFC
  371.        1486, Dover Beach Consulting, Inc., Internet Multicasting
  372.        Service, July 1993.
  373.  
  374.    [4] Borenstein, N., and N. Freed, "MIME  (Multipurpose Internet Mail
  375.        Extensions) Part One:  Mechanisms for Specifying and Describing
  376.        the Format of Internet Message Bodies", RFC 1521, Bellcore,
  377.        Innosoft, September 1993.
  378.  
  379.  
  380.  
  381.  
  382.  
  383.  
  384.  
  385.  
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394. Gwinn                                                           [Page 7]
  395.  
  396. RFC 1568                  SNPP - Version 1(b)               January 1994
  397.  
  398.  
  399. 10.  Security Considerations
  400.  
  401.    Security issues are not discussed in this memo.
  402.  
  403. 11. Author's Address
  404.  
  405.    R. Allen Gwinn, Jr.
  406.    Associate Director, Computing Services
  407.    Business Information Center
  408.    Southern Methodist University
  409.    Dallas, TX  75275
  410.  
  411.    Phone:  214/768-3186
  412.    EMail:  allen@mail.cox.smu.edu or allen@sulaco.lonestar.org
  413.  
  414.  
  415.  
  416.  
  417.  
  418.  
  419.  
  420.  
  421.  
  422.  
  423.  
  424.  
  425.  
  426.  
  427.  
  428.  
  429.  
  430.  
  431.  
  432.  
  433.  
  434.  
  435.  
  436.  
  437.  
  438.  
  439.  
  440.  
  441.  
  442.  
  443.  
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450. Gwinn                                                           [Page 8]
  451.